It is useful to be able to monitor and/or control access to a limited resource, especially in contexts in which placing more demands on the resource than the resource can meet may result in the resource becoming unavailable to operate even at the limited level it can support. One example of a limited resource is a network resource, such as a server or other system accessed via a network. Network-connected systems have a limited ability to process and exchange (e.g., send, receive) data. Errors or other failures can occur when the processing and/or communication capacity of such a system is exceeded, either as the result of high legitimate demand or malicious attack (e.g., so-called “denial of service” attacks). It is desirable to have an efficient way to detect when such an error or failure condition may occur and, if desired, to limit access or usage to a level that will enable such errors and/or failures to be avoided.
Even in contexts in which there is no particular risk that the processing and/or communication capacity of a system will be exceeded, it may be desirable to limit access by a particular user, process, or system, e.g. to implement a quality of service or other guarantee made with respect to that or some other user, process, or system. In other contexts, it would be useful to have an efficient way to detect use patterns that deviate from historic use and/or use patterns otherwise determined to be associated with normal or authorized use, such as detecting an unusual pattern of use of a credit card or other financial account, which may indicate the credit card and/or account information has been stolen.
One prior art approach to detecting and/or preventing a condition that might result in an error or failure, or that might result in a quality of service guarantee or some other relevant threshold or level of use being exceeded, e.g., has been to define a “sliding window” and track the demand made on the system (e.g., the number or cumulative size of the messages or other communications received) during a period defined by the window. For example, under one typical approach one might track how many messages were received in the last X seconds. In some cases, an alert may be sent or other responsive action taken if more than N messages were received in a period of X seconds. Or, in the case of a credit card or other account, a similar approach might be used to track how many transactions were charged to the account in a given hour, week, day, etc., with an alert being generated if the use exceeds a prescribed threshold. However, such an approach consumes a lot of processing and memory resources, as it is necessary to keep track of lots of data, such as which messages have been received (or transactions completed in the credit card example) and at what time, and continually (or at least periodically) perform computations on such information to determine the number of messages received within the sliding analysis window.
Therefore, there is a need for an efficient way to detect when demand, either collectively or from a particular source, exceeds the bandwidth or capacity available or allotted to satisfy the demand, such as from a network-connected system, and to detect patterns that may indicate unauthorized use.